home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-20 / nosvw.zip / NOSFILES.ZIP / NETROM.DOC < prev    next >
Text File  |  1991-09-18  |  21KB  |  521 lines
  1. ==========                                          NOSview [137]
  2. NETROM.DOC
  3. ==========
  4.  
  5.  
  6. INTRODUCTION
  7. ------------
  8. The NET/ROM support for the KA9Q package serves three purposes:
  9.  
  10. 1.  Existing NET/ROM networks may be used to send IP traffic.
  11.  
  12. 2.  NOS may be used as a NET/ROM packet switch.
  13.  
  14. 3.  NOS may be used to communicate with NET/ROM nodes, and its
  15. mailbox facility can accept connects over the NET/ROM network.
  16.  
  17.  
  18. SETTING UP THE NET/ROM INTERFACE
  19. --------------------------------
  20. No physical interface is completely dedicated to NET/ROM, which
  21. is as it should be.  You attach all your AX.25 interfaces, of
  22. whatever sort.  Then you attach the NET/ROM pseudo-interface
  23. ('attach netrom').  Then you identify to the NET/ROM software
  24. those interfaces you want to allow it to use, with the 'netrom
  25. interface' command.
  26.  
  27. The format of this command is:
  28. -----------------------------------------------------------------
  29. netrom interface tnc0 #GWA 192
  30. -----------------------------------------------------------------
  31.  
  32. The first argument is the name of the previously attached
  33. interface you want to use.  The second argument is the alias of
  34. your node, to be used in your routing broadcasts.  The alias is
  35. never used for anything else.  The last number is the NET/ROM
  36. quality figure.  This is used in computing the route qualities;
  37. it represents the contribution of this interface to the overall
  38. computation.  For a 1200 baud half-duplex connection, 192 is the
  39. right number.
  40.  
  41. You need a 'netrom interface' command for every interface you're
  42. going to use with NET/ROM.
  43.  
  44.  
  45. TRACING ON THE NET/ROM INTERFACE
  46. --------------------------------
  47. If you want to trace your NET/ROM datagrams, don't try turning on
  48. trace mode for the 'netrom' interface.  Nothing will break, but
  49. nothing will happen.  You should trace the individual AX.25
  50. interfaces instead.
  51.  
  52.  
  53. ROUTING BROADCASTS
  54. ------------------
  55. Once you have set up your interfaces, you need to set some
  56. timers.  There are two:  the nodes broadcast interval timer, and
  57. the obsolescence timer.  These are set in seconds, like the smtp
  58. timer.  You should usually set them to an hour.
  59.  
  60. If your local NET/ROM nodes broadcast every hour, but you want to
  61. do so every ten minutes, you can say:
  62. -----------------------------------------------------------------
  63. netrom nodetimer 600
  64. netrom obsotimer 3600
  65. -----------------------------------------------------------------
  66.  
  67. Every time the obsotimer kicks, the obsolescence counts for all
  68. non-permanent entries are decremented by one.  When the count for
  69. an entry falls below five, it is no longer broadcast.  When it
  70. falls to 0, it is removed.  The count is initialized at 6.  These
  71. will eventually be settable parameters; you can adjust them now
  72. by changing the initializers for the variables in the source
  73. file.
  74.  
  75. When you first come on the air, you can send out nodes broadcasts
  76. to tell the local nodes that you are available.
  77.  
  78. Use the command:
  79. -----------------------------------------------------------------
  80. netrom bcnodes tnc0
  81. -----------------------------------------------------------------
  82.  
  83. where tnc0 is the interface on which you want to send the
  84. broadcast.  Do this for every interface on which you want to do
  85. this.
  86.  
  87. By default, the NET/ROM code does not broadcast the contents of
  88. your routing table.  This is as it should be, since usually we
  89. just want to be the endpoints of communications rather than
  90. relaying NET/ROM traffic.
  91.  
  92. If you want to be a switch station, include the command:
  93. -----------------------------------------------------------------
  94. netrom verbose yes
  95. -----------------------------------------------------------------
  96.  
  97. in AUTOEXEC.NOS.
  98.  
  99. Sometimes you can hear broadcasts from nodes that can't hear you.
  100. If your routing table gets filled with these unusable routes,
  101. your node will grind to a halt.  The solution to this is node
  102. broadcast filtering, via the 'netrom nodefilter' command.  There
  103. is a filter list, which contains a list of callsigns and
  104. interfaces.  Then there is a filter mode, which indicates what to
  105. do with the list.
  106.  
  107. If the filter mode is 'none', no filtering is done.
  108.  
  109. If it is 'accept', then only broadcasts from the indicated
  110. stations on the indicated interfaces are accepted.
  111.  
  112. If it is 'reject', then all broadcasts except those from the
  113. listed stations on the listed interfaces are accepted.
  114.  
  115. Because the NET/ROM code cannot at this time recognize unusable
  116. routes and try alternates, the use of the filter command is
  117. strongly recommended to restrict broadcast acceptance to those
  118. nodes which you know you can reach.
  119.  
  120.  
  121. THE NET/ROM ROUTING TABLE
  122. -------------------------
  123. The next NET/ROM commands are those used for maintaining the
  124. routing table.  They fall under the 'netrom route' subcommand.
  125. 'netrom route add' adds a permanent entry to the routing table.
  126.  
  127. Its format is:
  128. -----------------------------------------------------------------
  129. netrom route add #GWB NS9GWB-5 tnc0 192 NR9AAA-2
  130. -----------------------------------------------------------------
  131.  
  132. This command adds an entry for NS9GWB-5, whose alias is #GWB,
  133. route quality 192, via NR9AAA-2 on interface tnc0.  Let's talk
  134. about what this means.
  135.  
  136. NS9GWB-5 is the "target" node, the ultimate destination of your
  137. packets routed by the NET/ROM network.
  138.  
  139. NR9AAA-2 is your neighbor, the NET/ROM node to which you pass the
  140. packet to be forwarded.  Since NR9AAA-2 may appear on more than
  141. one interface (the callsign may be used by more than one NET/ROM
  142. node on different bands), we specify that we are to use tnc0 to
  143. send the packet.
  144.  
  145. With NET/ROM, like IP, we don't know exactly what route a packet
  146. will take to its destination.  We only know the name of a
  147. neighbor which has indicated a willingness to forward that packet
  148. (of course, the neighbor may be the destination itself, but
  149. that's unlikely in our application).
  150.  
  151. NET/ROM sends the packet to the neighbor, with a network header
  152. specifying our callsign and that of the ultimate destination (in
  153. this case NS9GWB-5).
  154.  
  155. To drop the route to NS9GWA-5, you would type:
  156. -----------------------------------------------------------------
  157. netrom route drop NS9GWA-5 NR9AAA-2 tnc0
  158. -----------------------------------------------------------------
  159.  
  160. To see the contents of your routing table, you may type:
  161. -----------------------------------------------------------------
  162. netrom route
  163. -----------------------------------------------------------------
  164.  
  165. and to see the routing entries for an individual station you can
  166. type:
  167. -----------------------------------------------------------------
  168. netrom route info NS9GWA-5
  169. -----------------------------------------------------------------
  170.  
  171. You may not use an alias as an argument to the 'netrom route
  172. info' command.
  173.  
  174.  
  175. THE IMPORTANCE OF THE ROUTING TABLE
  176. -----------------------------------
  177. The NET/ROM routing table is analogous to the IP routing table:
  178. if there is nothing in it, your NET/ROM traffic will not go out.
  179. You must either manually enter a list of routes (perhaps via
  180. AUTOEXEC.NOS) or wait to receive routing broadcasts from your
  181. neighbors before your NET/ROM traffic will leave your station.
  182.  
  183. If you go to send packets via NET/ROM and nothing happens, even
  184. if you have trace mode on, make sure that the destination node is
  185. in your NET/ROM routing table.  If sending IP traffic, double
  186. check the ARP table for an appropriate NET/ROM ARP entry for the
  187. destination node (see below for more information on the use of
  188. the ARP table).
  189.  
  190.  
  191. INTERFACING WITH NET/ROMS USING YOUR SERIAL PORT
  192. ------------------------------------------------
  193. What if you have a NET/ROM node or nodes, and you'd like to
  194. attach them to your computer via their serial interfaces, and use
  195. NOS as a packet switch?  It's very easy: you have to attach those
  196. interfaces, using the 'attach asy' command, but specifying type
  197. 'nrs' instead of 'slip' or 'kiss'.
  198.  
  199. 'nrs' is the NET/ROM serial framing protocol, which is like KISS,
  200. but uses different framing characters and has an 8-bit checksum.
  201.  
  202. When you attach an nrs interface, it can be used for passing IP
  203. datagrams or AX.25 frames over serial lines or modems.  To use it
  204. for NET/ROM, you have to identify it to the NET/ROM code just
  205. like any other interface, with the 'netrom interface' command.
  206.  
  207.  
  208. THE TIME TO LIVE INITIALIZER
  209. ----------------------------
  210. The 'netrom ttl' command allows setting of the time-to-live
  211. initializer for NET/ROM datagrams.  A value of 16 is recommended
  212. for most networks.  Use more if you expect to go more than 16
  213. hops.  The default is 64.
  214.  
  215. The purpose of the ttl initializer is to prevent a packet from
  216. getting caught forever in routing loops.  Every router which
  217. handles the packet decrements the ttl field of the network
  218. datagram before sending it on, and when it reaches 0 it is
  219. discarded.
  220.  
  221.  
  222. USING NET/ROM SUPPORT FOR IP
  223. ----------------------------
  224. Now you know all the commands, but how do we actually use NET/ROM
  225. for IP communications?  This takes three steps:
  226.  
  227. 1.  Setting up the IP routing table.
  228. 2.  Setting up the ARP address table.
  229. 3.  Setting up the NET/ROM routing table.
  230.  
  231.  
  232. Setting up the IP Routing Table
  233. -------------------------------
  234. In all likelihood, you will use NET/ROM to gateway two IP
  235. subnets.  For example, station NS9GWA-5 in the diagram below is
  236. the gateway for Region 41, and NS9GWB-5 is the gateway for Region
  237. 42.
  238.  
  239. Stations NR9AAA-2, NR9BBB-2 and NR9CCC-2 are conventional NET/ROM
  240. switches.
  241.  
  242. The # names are NET/ROM aliases.
  243.  
  244.  
  245. _________________________________________________________________
  246. |                                                               |
  247. |     #BOB       #GWA                  #GWB       #LIZ          |
  248. |    NS9BOB-5...NS9GWA-5              NS9GWB-5...NS9LIZ-5       |
  249. |                  :                     :                      |
  250. |                  :                     :                      |
  251. |               NR9AAA-2...NR9BBB-2...NR9CCC-2                  |
  252. |                #AAA       #BBB       #CCC                     |
  253. |                                                               |
  254. |                                                               |
  255. |    <----Region 41---->              <----Region 42---->       |
  256. |         44.131.41.xx                     44.131.42.xx         |
  257. |                                                               |
  258. |_______________________________________________________________|
  259.  
  260.  
  261. Let's say we're on the Region 41 subnet, and we want to talk to
  262. someone in Region 42.  NS9BOB will have an IP routing table entry
  263. like this:
  264. -----------------------------------------------------------------
  265. route add region42/24 tnc0 ns9gwa
  266. -----------------------------------------------------------------
  267.  
  268. where 'region42' is defined in DOMAIN.TXT as:
  269. -----------------------------------------------------------------
  270. region42.ampr.org.  IN A  44.131.42.00
  271. -----------------------------------------------------------------
  272.  
  273. The routing table entry specifies that NS9GWA should get all
  274. packets for the Region 42 subnet via interface tnc0.
  275.  
  276.  
  277. The Region 41 gateway NS9GWA has this IP routing table entry:
  278. -----------------------------------------------------------------
  279. route add region42/24 netrom ns9gwb
  280. -----------------------------------------------------------------
  281.  
  282. Now, when the IP layer at NS9GWA gets datagrams for Region 42, it
  283. knows that they have to go via NET/ROM to NS9GWB.  Notice that we
  284. don't specify a "real" interface, like tnc0 or nr0, in the route
  285. entry.  The NET/ROM network layer will pick the right interface
  286. based on its NET/ROM routing table (see below).
  287.  
  288.  
  289. Setting up the ARP table
  290. ------------------------
  291. As 'ns9gwb' is an IP address and not an AX.25 callsign, the
  292. NET/ROM send routine called by the IP layer needs to map from
  293. 'ns9gwb' to an AX.25 address.
  294.  
  295. It does this via a manually added ARP entry:
  296. -----------------------------------------------------------------
  297. arp add ns9gwb netrom NS9GWB-5
  298. -----------------------------------------------------------------
  299.  
  300. [The use of the ARP table for this purpose is a kind of fudge,
  301. since there is no way to do automatic address resolution for
  302. NET/ROM, and ARP messages are never sent or received for NET/ROM
  303. nodes.  However, the ARP table does contain precisely what we
  304. have here: mappings from IP addresses to callsigns, and it saved
  305. a lot of code to do it this way.]
  306.  
  307. Notice also that no digipeaters are ever specified in the ARP
  308. table.  (Use 'ax25 route' if you need to specify digipeaters).
  309.  
  310. Also, the callsign to which we are mapping is the final
  311. destination of the packet, not the non-destination neighbor.
  312. That neighbor will be picked based on the NET/ROM routing table.
  313.  
  314.  
  315. Setting up the NET/ROM Routing Table
  316. ------------------------------------
  317. To launch the packets towards the Region 42 gateway NS9GWB via
  318. the conventional NET/ROM network, NS9GWA will need a NET/ROM
  319. routing table entry.
  320.  
  321. For example:
  322. -----------------------------------------------------------------
  323. netrom route add #GWB NS9GWB-5 tnc0 192 NR9AAA-2
  324. -----------------------------------------------------------------
  325.  
  326. NR9AAA-2 is the local NET/ROM node at the entry point to the
  327. NET/ROM network, and will hopefully contain a routing table entry
  328. for NS9GWB-5.
  329.  
  330. Also, NS9GWA needs to broadcast its own alias to the NET/ROM
  331. network, so that a routing table entry finishes up in NR9CCC-2
  332. (for use by NS9GWB and any other node wishing to contact NS9GWA).
  333.  
  334. To do this, NS9GWA needs the additional commands:
  335. -----------------------------------------------------------------
  336. netrom interface tnc0 #GWA 192
  337. netrom route add #AAA NR9AAA-2 tnc0 100 NR9AAA-2
  338. -----------------------------------------------------------------
  339.  
  340.  
  341. So, as a summary, let's look at what happens when Bob sends a
  342. packet to Liz.
  343.  
  344. 1.  By reference to DOMAIN.TXT, NS9BOB determines that NS9LIZ is
  345. in Region 42.  The IP table entry for subnet Region 42 specifies
  346. that the packet should go to NS9GWA, and so the packet travels by
  347. IP to the gateway.
  348.  
  349. 2.  NS9GWA receives the incoming IP packet addressed to Liz in
  350. Region 42, and determines that it should go via NET/ROM to the
  351. Region 42 gateway NS9GWB.
  352.  
  353. 3.  NS9GWA passes the packet to the NET/ROM send routine, and
  354. that routine uses the ARP table to translate NS9GWB's IP address
  355. to the callsign 'NS9GWB-5'.
  356.  
  357. 4.  NS9GWA then passes the packet to the NET/ROM routing code.
  358. That code checks to see if the destination callsign NS9GWB-5 is
  359. the same as that of any of its assigned NET/ROM interfaces; that
  360. is, it checks to see if this node is the final destination for
  361. the packet.
  362.  
  363. Since it isn't, it puts a network layer header on it, and looks
  364. for NS9GWB-5 in its NET/ROM routing table.
  365.  
  366. 5.  Using the table entry, NS9GWA routes the packet to NR9AAA-2.
  367. From there it travels to the Region 42 gateway NS9GWB (presumably
  368. via NR9BBB-2 and NR9CCC-2).
  369.  
  370. 6.  When NS9GWB receives the incoming packet, it determines that
  371. it has reached its final NET/ROM destination.  Because NS9GWB is
  372. a NOS node, not an ordinary NET/ROM switch, the packet is now
  373. passed up to the IP layer.
  374.  
  375. 7.  The IP layer then discovers that the packet is destined for
  376. Liz, and so routes it to her in the normal way.
  377.  
  378.  
  379. THE NET/ROM TRANSPORT LAYER
  380. ---------------------------
  381. NET/ROM transport is the protocol used by NET/ROM node to
  382. communicate end-to-end.  When a user attaches to a NET/ROM via
  383. AX.25, and asks for a connect to a node in the NODES list, his
  384. local NET/ROM tries to open a transport connection to the
  385. destination node over the NET/ROM network.  NET/ROM transport
  386. packets are carried in NET/ROM network datagrams, just like IP
  387. datagrams.
  388.  
  389. You shouldn't use NET/ROM transport when connecting to other
  390. TCP/IP stations.  TCP is a much better protocol than NET/ROM
  391. transport, and makes better use of available bandwidth.  Also,
  392. BM/ELM and SMTP are more convenient to use than a TCP/IP
  393. station's mailbox facility.
  394.  
  395. However, for communicating with AX.25 users via the NET/ROM
  396. network, the transport facilities in NOS will work better (and
  397. more easily) than the traditional method of connecting to your
  398. local node via AX.25.
  399.  
  400.  
  401. CONNECTING VIA NET/ROM TRANSPORT
  402. --------------------------------
  403. To connect to the node whose alias is #BBB and whose callsign is
  404. NR9BBB-2, you can issue either of the following two commands:
  405.  
  406. -----------------------------------------------------------------
  407. netrom connect #BBB
  408. netrom connect NR9BBB-2
  409. -----------------------------------------------------------------
  410.  
  411. If #BBB:NR9BBB-2 is in your NET/ROM routing table, your station
  412. will transmit a connect request to the appropriate neighbor used
  413. to reach NR9BBB-2.
  414.  
  415. NET/ROM transport sessions are very much like those for AX.25.
  416. You can use the 'disconnect', 'reset', 'kick', 'upload' and
  417. 'record' commands, and the 'session' command to switch sessions.
  418.  
  419.  
  420. DISPLAYING THE STATUS OF NET/ROM CONNECTIONS
  421. --------------------------------------------
  422. The command 'netrom status' is used to display the status of all
  423. NET/ROM connections, which will include those used in keyboard
  424. sessions as well as ones attached to the mailbox.
  425.  
  426. For more detailed information on a session, you can use the
  427. address of the NET/ROM control block:
  428. -----------------------------------------------------------------
  429. netrom status <&CB>
  430. -----------------------------------------------------------------
  431. where <&CB> is the hex address given in the short form of the
  432. 'netrom status' command.
  433.  
  434.  
  435. NET/ROM TRANSPORT PARAMETERS
  436. ----------------------------
  437. The NET/ROM transport parameters may be set with the various
  438. NET/ROM subcommands.  Their meanings are listed below:
  439.  
  440. acktime: This is the ack delay timer, similar to the AX.25 T2
  441. timer.
  442.  
  443. choketime: The time to wait before breaking a send choke
  444. condition.  Choke is the term for NET/ROM flow control.
  445.  
  446. irtt:  The initial round trip time guess, used for timer setting.
  447.  
  448. qlimit:  The maximum length of the receive queue for chat
  449. sessions.  This is similar to 'ax25 window'.
  450.  
  451. retries:  Maximum retries on connect, disconnect, and data
  452. frames.
  453.  
  454. window:  Maximum sliding window size, negotiated down at connect
  455. time.
  456.  
  457.  
  458. THE MAILBOX
  459. -----------
  460. The AX.25 mailbox also accepts NET/ROM connections.  The 'mbox
  461. on' and 'mbox off' commands control whether the mailbox is turned
  462. on for NET/ROM as well as AX.25, and the 'mbox' command displays
  463. current mailbox connects of both types.
  464.  
  465. Many people have observed that the AX.25 mailbox requires the
  466. user to enter a carriage return to bring up the banner and
  467. prompt.  This is because of certain defects of that protocol when
  468. it is used as the link layer for several different higher level
  469. protocols, and is unavoidable.
  470.  
  471. The NET/ROM mailbox does not require the carriage return, and
  472. will be activated as soon as the incoming connection is made.
  473.  
  474.  
  475. WHERE TO GO FOR MORE INFORMATION
  476. --------------------------------
  477. The paper "Transmission of IP Datagrams over NET/ROM Networks"
  478. (by Dan Frank, W9NK) appeared in the Seventh ARRL Networking
  479. Conference papers, available from the ARRL.  There he describes
  480. the more technical details of how the NET/ROM network support
  481. works.
  482.  
  483. If you want to learn about NET/ROM, talk your local NET/ROM or
  484. TheNET operator out of his or her manual.  If you want to learn
  485. more, read the source code.
  486.  
  487. There has been a great deal of controversy about TheNET, a no-
  488. charge NET/ROM clone for TNCs.  This is not the place to discuss
  489. the truth of the charges leveled by Software 2000 against its
  490. authors, but that situation has led to W9NK making the following
  491. statement:
  492.  
  493. "The NET/ROM transport support in NET.EXE [NOS] was not taken in
  494. any way, shape or form from NET/ROM (whose source I have never
  495. seen) or from TheNET.  The protocol code is based on protocol 6
  496. from Tanenbaum's excellent book, "Computer Networks", as a
  497. moderately careful reading of both should show.  The source code
  498. is freely distributed, so the curious reader should have the
  499. opportunity to check this assertion if he or she so desires.
  500.  
  501. "The smoothed round trip time calculation, which is not done in
  502. 'real' NET/ROMs (and should be, by the way -- they'd work a whole
  503. lot better) is adapted from that used by KA9Q in the TCP protocol
  504. in NET.  The dicey business of adapting it to a sliding windows
  505. protocol with selective retransmission was done by me, all alone,
  506. after my cries for help on the tcp-group mailing list went
  507. unanswered :-).
  508.  
  509. "I have taken the precaution of copyrighting the NET/ROM code in
  510. NET.  It may be freely distributed for non-commercial purposes,
  511. in whole or in part, and may be used in other software packages
  512. such as BBS systems if so desired, so long as the copyright
  513. notice is not removed from the source files, and the program in
  514. which it is used displays 'NET/ROM code copyright 1989 by Dan
  515. Frank, W9NK' when it starts up.
  516.  
  517. "Any person who wishes to distribute the code, or anything based
  518. on the code, for commercial purposes will find me very
  519. reasonable, but rather insistent about being compensated for the
  520. hours I've spent working on it".
  521.